Description

One Line Summary

PR 5 of 6 against the Identity Verification integration branch — exposes the developer-facing IV API (IUserJwtInvalidatedListener, updateUserJwt, login JWT storage) and bridges PR 3's JwtTokenStore invalidation events to a multi-subscriber EventProducer on UserManager.

Details

Motivation

PR 3 moved the JWT-invalidation event source onto JwtTokenStore.invalidateJwt and removed the cross-cutting setJwtInvalidatedHandler from IOperationRepo. The replacement was supposed to be: UserManager subscribes to JwtTokenStore directly, and exposes the developer-facing event surface. PR 4 added executor-side JWT attachment but left the API unwired.

This PR closes the loop:

1. Stores the JWT. OneSignal.login(externalId, jwt) finally writes the token to JwtTokenStore so PR 4's executor extensions can find it. Also handles same-user-with-new-token (refresh) and adds a dedicated updateUserJwt(externalId, token) method for the post-401 refresh case.
2. Surfaces invalidation events. JwtTokenStore.onJwtInvalidated → UserManager → EventProducer<IUserJwtInvalidatedListener> → developer listener. Multi-subscriber (matches the codebase's existing EventProducer idiom). Async dispatch on Dispatchers.Default so the developer's callback doesn't run on the SDK's internal thread.
3. Listener replay for late registration (fix(jwt): race conditions and IAM reliability issues with identity verification enabled #2613 commit 2 equivalent). If the SDK invalidates a JWT before the developer's listener is wired up (typical during early app startup), the cached event is replayed to listeners that subscribe later. Cleared on logout.

Scope

New public types (in com.onesignal):

• IUserJwtInvalidatedListener — fun interface for Kotlin SAM-conversion convenience
• UserJwtInvalidatedEvent(externalId: String) — event payload

IOneSignal gains three methods:

• updateUserJwt(externalId, token) — store JWT + force-execute the queue so deferred ops dispatch with the fresh token.
• addUserJwtInvalidatedListener(listener) — multi-subscriber, with replay on late registration.
• removeUserJwtInvalidatedListener(listener).

The pre-existing login(externalId, jwtBearerToken) overload + loginSuspend were already in IOneSignal; this PR finally wires the JWT param through to JwtTokenStore.

UserManager:

• Implements IJwtUpdateListener and subscribes to JwtTokenStore in init — replaces PR 3's setJwtInvalidatedHandler bridge with a direct event-source subscription.
• Holds an EventProducer<IUserJwtInvalidatedListener> and a CoroutineScope(SupervisorJob() + Dispatchers.Default) for async fan-out.
• fireJwtInvalidated(externalId) — caches the event for replay, schedules async fire with per-listener runCatching (one throwing subscriber doesn't poison others — matches the same pattern from PR 3's JwtTokenStore.invalidateJwt fix).
• addJwtInvalidatedListener — subscribes, then if lastJwtInvalidatedExternalId != null, schedules a replay to the new listener.
• clearLastJwtInvalidated() — clears the replay cache. Called from OneSignalImp.logout() / logoutSuspend() so a stale event from a previous user doesn't fire for a new session.
• New constructor param: JwtTokenStore. DI registration adds provides<UserManager>() so OneSignalImp can resolve the concrete class for listener delegation.

LoginHelper:

• New constructor param: JwtTokenStore.
• In switchUser(externalId, jwtBearerToken):
  • New-user path: stores the JWT before userSwitcher.createAndSwitchToNewUser so when the queued LoginUserOperation dispatches, the JWT lookup in hasValidJwtIfRequired already succeeds.
  • Same-user path (no switch needed): still updates the stored token if a new JWT was supplied — supports developers calling login(sameId, refreshedJwt) to refresh.
• Class visibility tightened to internal class (was public) since the constructor now exposes internal JwtTokenStore.

OneSignalImp:

• Injects JwtTokenStore via services.getService<JwtTokenStore>() (it was already in DI from PR 1).
• Implements the three new IOneSignal methods, delegating listener add/remove to services.getService<UserManager>().
• logout() and logoutSuspend() call clearLastJwtInvalidated() before the user-switch so subsequent listener registrations don't replay the previous user's invalidation.

Layering / consistency

• Replaces PR 3's plumbing setter (setJwtInvalidatedHandler is already gone from IOperationRepo); the bridge is now JwtTokenStore.IJwtUpdateListener.onJwtInvalidated → UserManager → EventProducer.
• Migration scenario from feat: identity verification 5.8 #2599 (HYDRATE-IV-required + existing externalId + no JWT → fire listener) is intentionally not ported — verified iOS does not do this either (only fires on actual 401s). Customers enabling IV are expected to ship code that supplies JWTs for active users; the SDK only signals on actual 401 responses.

What is NOT in this PR

• Logout IV-aware behavior (disable push sub on IV-required logout) + IAM IV integration + RYW plumbing — PR 6 (final).
• The LoginHelper.switchUser JWT optimization for the migration scenario — out of scope (we don't fire the migration event, see above).

Testing

Unit testing

UserManagerTests (4 new):

• JwtTokenStore.invalidateJwt fires registered IUserJwtInvalidatedListener — end-to-end via the real JwtTokenStore + UserManager subscription.
• listener replay: subscribers added after fire receive the most recent event — verifies the replay cache is consulted on addJwtInvalidatedListener.
• clearLastJwtInvalidated stops replay for new subscribers — verifies the logout-path clears the cache.
• removeJwtInvalidatedListener stops further notifications — verifies unsubscribe.

LoginHelperTests (2 new):

• login with JWT stores token in JwtTokenStore before enqueueing op — new-user path + JWT storage.
• login with same externalId + new JWT updates the stored token — same-user-refresh path; asserts no user-switch happens but JWT is updated.

All affected tests pass locally. Two pre-existing SDKInitTests failures are unrelated and consistent with the integration branch baseline.

Manual testing

Not applicable for this PR — the wired listener fires only when JwtTokenStore.invalidateJwt is called, which happens from PR 4's handleFailUnauthorized in response to a 401. End-to-end manual testing requires the integration branch to be merged + a backend with jwt_required=true.

Affected code checklist

• Notifications
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes (new: IUserJwtInvalidatedListener, UserJwtInvalidatedEvent, IOneSignal.updateUserJwt, IOneSignal.addUserJwtInvalidatedListener, IOneSignal.removeUserJwtInvalidatedListener. Existing login(externalId, jwt) semantics: JWT now actually stored.)

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing — wires the developer-facing IV API on top of PR 3's invalidation event source and PR 4's executor JWT attachment.
• Any Public API changes are explained in the PR details and conform to existing APIs (matches the addObserver/removeObserver shape used by IUserStateObserver, etc.)

Testing

• I have included test coverage for these changes
• All automated tests pass locally (pre-existing SDKInitTests failures are unrelated — same 2 on integration branch)
• Manual testing N/A — wiring is consumed only when 401s drive JwtTokenStore.invalidateJwt, which requires a live IV-enabled backend.

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item